home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Night Owl 6
/
Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso
/
049a
/
ommm_155.zip
/
OMMM.HST
< prev
next >
Wrap
Text File
|
1990-11-15
|
16KB
|
373 lines
oMMM 1.55 - Final release (Hopefully!?!)
Added support for file attaching message with file names begining with
^ and #. File names begining with a ^ will be deleted by your mailer after
being sent. Files starting with a # will be 0'ed out (0 bytes in length)
by your mailer after being sent.
Code was cleaned up a bit.
Hopefully, the version display will now give the proper credit where
credit is due as far as development for oMMM.
oMMM 1.54ß - Beta release (Patients with Heart Conditions should avoid).
oMMM will now support Points (I think?). To enable this simply insert the
following verb in the oMMM.CFG file:
POINTNET ###
where the ### is the network address the message is to be re-routed to. For
example, my address is 109/315. If a message is found addressed to me as
109/315.2 and I have the verb POINTNET 0 in my CFG file, the message would be
re-routed to 0/2.
In short:
Verb: POINTNET ###
Message: Z:N/n.P
re-route to Z:###/P
It is rumored that Opus will support points using WaZoo/Yahoo protocol
with a re-routed message going to a network address of 0. In the above
example, if another Opus calls me with an address of 109/315.2, any outbound
mail for 0/2 will be sent.
Confused? Good, so am I, so I think I'll let this stuff take it's course
until real docs are done.
- Jon Marshall
oMMM 1.53 - Beta release.
oMMM now automatically changes an Opus date found in a netmail msg to
the standard FTSC format. Opus 1.12 uses FTSC date formats in echomail, and
will use FTSC date formats in netmail in a future version.
oMMM now supports as an option, day and time range in the schedule verbs.
SCHED <tag> <day> [<start_time> <end_time>]
You'll have to have at least 1 schedule to make oMMM work
properly. Here's an explanation of the options:
<tag>
The schedule tag is a single character, and is not case sensitive.
If you'd like to override a specific day/time, use the
command line '-s' option followed by the schedule tag.
<day>
The day may be any combination of the following:
All . . Every day
Week . . Week days only (Monday through Friday)
WkEnd . Weekend days only (Saturday and Sunday)
Sun . . Sunday only
Mon . . Monday only
Tue . . Tuesday only
Wed . . Wednesday only
Thu . . Thursday only
Fri . . Friday only
Sat . . Saturday only
In addition, you may join the days with the '|' symbol.
As an example, "Sun|Mon" would mean the schedule would
only be active on Sunday or Monday.
<start_time> <end_time>
This is the starting and ending time of the schedule
(in military time). 00:00 to 23:59.
- John Valentyn
oMMM 1.52 - Maintenance Release.
Yet another termite exterminated. UnHold, UnCM and UnDirect verbs should
now work when running in the default Add mode of Ommm.
- Jon Marshall
oMMM 1.51 - Maintenance Release.
This is strictly a maintenance release of the oMMM.EXE file. This
version will allow you to do a wildcard file attach and multiple file
attaches where each file is seperated by a semi-colon (;), a comma (,) or a
space ( ) on the subject line. You message editor may not like this, i.e.
Opus 1.10 reports the file can not be found, but oMMM will expand the
information out so your mailer will pick it up.
- Jon Marshall
Documentation supplement for oMMM 1.50
This document is intended to be used in addition to the excellent
oMMM document written by Alan Applegate titled version 1.30.
This document explains the new features for version 1.50, and also
attempts to point out the diffences between 1.50 and prior versions.
HIGHLIGHTS
==========
- Verbs OPUS and BINKLEY are now simply NAKED. Ommm operates in a request
mode compatible with Opus. Use the verb NAKED or option -R to generate file
requests ALA Binkley Style.
- Ommm now defaults to Forwarding messages, and adding to any exisiting bundle
of a different flavor. Therefore making routing verbs ARCADDCM, etc...
obsolete. They are still there and by using the NO_ADD verb or -U options you
can use them. If no one objects, ADD routing verbs will dissapear in a later
release. As for Forwarding messages, use the NO_FORWARD verb (FORWARD verb is
no longer valid) or the -F option.
*** NOTE ***
the -F option now toggles the forwarding setting of Ommm.
- Routing verbs with 'ARC' (except the ADD verbs) are being replaced as
follows:
ARCCM == STUFFCM
ARCDIRECT == STUFFDIR
ARCHOLD == STUFFHOLD
both are valid, but the ARC verbs will disappear in a future release, start
converting.
- Check the OMMM.CFG file, it's now a complete source of whats valid and
what isn't. Also do an OMMM -? for a list of command line options.
- NOTE: OMMM.CFG is REQUIRED!
- Routing now acts as documented.
- ADDRESS verb in OMMM.CFG MUST appear with full specifications as:
ZZ:TT/NN.PP
for example:
ADDRESS 1:109/315.0
- Gone is the -I and Info_path in OMMM.CFG. This will allow OMMM to work with
other mailers.
- The -Z and Zone are gone. Use the ADDRESS verb with zone 0: for no zone
mailing or #: for acting in zone aware mode as the -Z option use to do.
- The -F now toggles mail forwarding (use to be -N).
- The -N now toggles normalizing the outbound area (use to be -F).
- To make file requests with mailers that treat .REQ files as normal mail use
the -R or NAKED verb in OMMM.CFG. This will create 'naked' request files for
mailers like Binkley. If your mailer requires a FLO packet such as Opus, do
not use these options. The -R and NAKED replace -B and Binkley.
- The -B, Binkley and Opus verbs are no longer supported. See the -R and NAKED
verb above.
- ALL routing verbs dealing with ZOO, ZIP, etc... (i.e. ZOOCM, ZI1direct) are
gone. Use the DEFINE_STUFFER and STUFFER verbs for other kinds of ARCMail.
COMMAND LINE OPTIONS
====================
The command line switches are intended to override values set in the
oMMM.CFG file. The only switch which would normally be used is the
-s(schedule) switch.
-aZ:N/n use the address Zone:Net/Node as the default
instead of the first address in the CFG file
-bOMMM_CFG alternate configuration file name
-cROUTEFILE the file with routing information
-f Toggles forwarding messages from other nodes
-g tells oMMM to gate route interzone messages
-hHOLDPATH the outbound directory for the OUT/FLO files
-mMESSAGEPATH the directory containing netmail messages
-n Toggles normalizing 'no-send' packets
-o tells oMMM to use the old .MO? extensions and not .TU1, etc.
-pPRESCANPATH the file with routing information to be used
before message scanning takes place
-q tells oMMM to run quietly (and marginally faster)
-r tells oMMM to make naked file requests
-sSCHED a single character for this schedule tag
-tDAYS delete bundles more than 'DAYS' days old
-u tells oMMM not to add to exisiting bundles.
-xSIZE maximum bundle size in kbytes (default 512k).
FILE COMPRESSOR SUPPORT
=======================
oMMM now supports any file compressor that's out there, as long as
that compressor's command line adheres to the following convention:
name <options> compressed_file_name filename_to_be_compressed
All you have to do is define it in the CFG file, and declare which
nodes are to be bundled by that file compressor.
The advantages of using this method are:
1. No need for separate routing verbs for each compressor.
2. Compression type is specified for each node only once. This
eliminates the chance of overlooking a node which may be declared
in more than one place in the route file.
3. Users can add a new compressor without any source code changes.
When stuffers are declared the arce/pkarc switch is ignored, and
the first STUFFER declared will be used as the default. This allows you
to have a default other than ARCE or PKARC. Be careful here, since many
nodes cannot support other file compressors.
syntax: DEFINE_STUFFER <tag> <dos command line and arguments>
This statement is used in conjunction with the STUFFER command.
The tag must be unique, since it is used in the STUFFER command
to identify the compressor. The tag can be anything you want.
The dos command line and arguments is the same one you would use
to invoke the file compressor from the dos prompt or in a bat file,
to add a file to the compressed file (which may have to be created).
Do not specify the option to delete the file once it's added, since
oMMM will delete the packet only if the compressor returns a result
code of 0.
The first STUFFER defined will be used as the default STUFFER.
This means that any node declared in the route file as receiving
compressed bundles (ARCxxx or ONExxx) and not specified in any
of the STUFFER statements, will be compressed by the first
DEFINE_STUFFER statement found in the CFG file.
WARNING!!!!!
YOU DO NOT WANT TO CREATED "MIXED" BUNDLES. SOME COMPRESSORS
WILL BLINDLY ADD TO A COMPRESSED FILE CREATED BY ANOTHER
COMPRESSOR, WHICH "GRUNGES" THE FILE, SINCE NO COMPRESSOR CAN
DE-COMPRESS IT. THE BEST TIME TO ADD OR CHANGE A FILE COMPRESSOR
FOR A GIVEN NODE IS WHEN THERE IS NOTHING IN THE OUTBOUND DIRECTORY
FOR THAT NODE. IF YOU CHANGE THE COMPRESSOR FOR A NODE, AND THERE
IS A BUNDLE FOR THAT NODE IN THE OUTBOUND, YOU MUST MANUALLY
UNCOMPRESS THAT BUNDLE WITH THE OLD COMPRESSOR, AND THEN COMPRESS
ALL THE PACKETS WITH THE NEW COMPRESSOR.
syntax: STUFFER <tag> <[zone:][net/]node ...>
Declare which nodes are to be bundled by one of the compressors
defined. The tag must be the same declared in one of the
DEFINE_STUFFER statements. There is no limit on # of nodes that
can be declared for any stuffer, other than a line length limit
of 512 characters per line. Therefore a tag may be used more
than once. If no zone is declared, the default zone will be used.
Shorthand net/nodes may also be used.
Here is an example of the STUFFER declarations for the .CFG file:
Define_Stuffer ARCA arca
Define_Stuffer PKARC pkarc -oct a
Define_Stuffer PAK pak a
Define_Stuffer ZOO zoo -add
Define_Stuffer ZIP pkzip -a
Define_Stuffer LHARC lharc a /m
Stuffer LHARC 307/1 7 381/48
Stuffer PKARC 114/23
Stuffer ZIP 103/501 114/18 30 33 36 45 47 58 115/876 128/40 303/3 307/9
Stuffer ZIP 308/30 309/2 3 104/312 300/11 15/13 305/103
Stuffer PAK 114/80
Stuffer ZOO 3:123/456
Stuffer ARCA 2:123/4567
Thanks to Jeffrey J. Nonken for the following features.
BUNDLE SIZE LIMIT
=================
oMMM 1.50 now has a way of limiting bundle sizes and of
automatically deleting unsent bundles after a certain date. There
are limitations to both these functions, however.
Size limit: you can invoke a packet size limit by including a -x
parameter on the command line or the keyword 'maxarc' in the
configuration file. Follow the keyword or the parameter with
the desired limit size in kilobytes. For example, if you wish
packets to be limited to 256 kilobytes, do this:
oMMM -x256 ...
If you leave the number off the command line, or if you specify
less than 1, it will default to 512k.
When oMMM 1.40 compresses and exports a packet, it simply adds it
to the first existing bundle it finds; or if there is a truncated
packet, it deletes the old one, increments the extention, and
starts a new one. oMMM 1.50 , however, looks for several bundles
and appends only to the last one, if it exists, deleting all
truncated bundles. If the packet size limitation option has been
invoked, oMMM 1.50 will check the bundle size before appending;
if it is too large, oMMM will create a new bundle and add it to
the outbound list.
oMMM 1.50 does not actively limit the bundle size; if the packet
it adds brings the bundle size over the requested size limit,
oMMM will not attempt to do anything about it. oMMM will simply
not add to a bundle that already meets or exceeds the requested
size limit. It is up to the export program to limit packet sizes.
oMMM will use the .MO?, .TU?, .WE? extension naming convention
for bundles unless the sysop overrides with the -o parameter, in
which case oMMM only uses the .MO? extension. However, when the
size limit feature is invoked, if the bundle .MO9 exceeds the
size limit, oMMM will override the -o parameter and name the next
bundle .TU0. This ONLY happens if the bundle exceeds the size
limit.
In the unlikely event that 69 of the 70 possible bundles get
filled up, oMMM will override the size limit feature and continue
to append to the last bundle. (This has not been tested.)
KILL OLD BUNDLES
================
Old bundles: if you have a system that fails to pick up its mail
regularly, you may want to automatically delete its old bundles.
oMMM will not seek these out, but if it finds an old bundle
destined for a system it's processing, it can automatically
delete it for you. This is especially useful for a system that
gets sent mail regularly, when you have a bundle size limitation
set. Invoke the automatic 'timed' deletion with the -t parameter
on the command line, or with the keyword 'oldbundle' in the
configuration file, followed by the number of days you want to
wait before deleting. For example:
oMMM -t7 ...
This causes oMMM to delete any bundle it finds that is more than
seven days old. If you specify less than 1 it will default to 7
days.
Because of the way this function is implemented, if the bundle in the
example is as much as 7 days and 1 second old, oMMM will delete
it. So you could see oMMM delete one bundle that has the same
date stamp as another that it leaves alone.
Again, oMMM does not actively seek out old bundles. It only
checks the dates of existing bundles that it happens to be
processing. However, if it finds a single bundle that is too old,
it will delete it and then re-use its name for the new packet.
Since the intended recipient never got the deleted bundle, I
cannot think of any practical reason to increment the name.
However, if it bothers enough people, I will go ahead and add the
code to do that.
There is an extremely unlikely situation that could come up: oMMM
finds there are 69 bundle names used, the last one exceeds the
size limitation, and there is at least one aged bundle. oMMM will
delete the aged bundle(s) and append to the last one, even though
it is oversized. (The next time oMMM is run it will find there
are less than 69 bundles used and create a new one.) This is an
artifact of the structure of the code, and considering how
unlikely an occurrance this is, I refuse to bother to make it
work differently.